1. Technical Field
The subject invention relates generally to the field of computers and computer software and, more particularly, to program code conversion methods and apparatus useful, for example, in code translators, emulators and accelerators which encounter exception signals.
2. Description of Related Art
An exception is a condition that changes the normal flow of control in a program. An exception may be generated (“raised”) by hardware or software. Hardware exceptions include such signals as resets, interrupts, or signals from a memory management unit. Exceptions may be generated by an arithmetic logic unit or floating-point unit for numerical errors such as divide-by-zero, for overflow or underflow, or for instruction decoding errors such as privileged, reserved, trap or undefined instructions. Software exceptions are varied respectively across various software programs and could be applied to any kind of error checking which alters the normal behavior of the program. An exception handler is special code which is called upon when an exception occurs during the execution of a program. If the program does not provide a handler for a given exception, a default system exception handler will be called, usually resulting in abortion of the program being run and an error indication being returned.
Exception signals are a common mechanism for raising exceptions on many operating systems. The POSIX standard, which is adhered to by many operating systems, particularly Unix-like systems, specifies how this mechanism should behave so that exception signals are broadly similar across many systems. The most common events that trigger exceptions are when a process implemented by a program tries to (i) access an unmapped memory region or (ii) manipulate a memory region for which it does not have the correct permissions. Other common events that trigger exception signals are (iii) the receipt of a signal sent from another process, (iv) the execution by a process of an instruction that the process does not have the privilege level to execute, or (v) an I/O event in the hardware.
Due to the interruption of the program being executed, the delivery of an exception signal by the operating system to an exception handler normally includes a captured state of the subject processor when the exception occurred. This state can be very difficult to determine and costly to generate. In order to avoid these costs, it is generally preferable to avoid intentionally issuing exceptions unless there are no better alternatives.
Some representative exception signals issued by operating systems to define certain events are described in Table 1.
TABLE 1Exception SignalsSignalDescriptionSIGHUP“Hangup”—commonly used to indicate to a process thatits configuration has changed, and that it should re-readits config file.SIGINT“Interrupt”—usually means Ctrl-C has been pressed by theuser.SIGILL“Illegal Instruction”—the processor generates this when aninvalid instruction opcode is encountered.SIGTRAP“Breakpoint”—often used by debuggers.SIGBUS“Bus Error”—usually generated by the processor to indicatean invalid memory access. This is usually an access to anunallocated or unaligned memory address.SIGSEGV“Segmentation Violation”—generated by the processorwhen a user process has tried to do something notpermissible in user mode. For example, trying to execute aprivileged instruction, or trying to write to part of the kernelmemory would both raise this signal.SIGALRM“Alarm Clock”—a process can make the alarm( ) systemcall, which requests the delivery of this signal n secondslater.SIGTERM“Terminate”—polite request for a program to think aboutexiting, if it's not too inconvenient.SIGQUIT“Quit”—Firm request for a program to exit, now please!SIGKILL“Die”—immediately terminates the process. This signalcannot be intercepted by a signal handler.
Exception signals can come from two sources: (1) directly from a subject program or (2) from the operating system or another process. Some exception signals are generated as a direct result of an instruction executed by the subject program. For example, if a subject program executes an illegal opcode, then SIGILL is raised. Similarly, if the subject program attempts an illegal memory access then SIGSEGV is raised. These are referred to as in-band signals. Exception signals can also be generated externally, either by the operating system or by another process. SIGHUP and SIGALRM are examples of these. These externally generated exception signals are called out-of-band signals.
From a subject program's point of view, an exception signal can occur at any time. When an exception signal occurs, the operating system interrupts the execution of the signaled program and invokes a signal handler function. The operating system maintains a process-specific function table which maps each signal to a particular signal handler. The operating system also defines default signal handlers for all exceptions. The default signal handlers either take predefined actions or simply ignore the signal.
For example, in Unix, a program can override a default signal handler by invoking the sigaction( ) system call. Sigaction( ) allows the program to specify what action the operating system should take when a particular exception signal is received. The action can be: (1) ignore the exception signal; (2) call the default signal handler; or (3) call a specialized signal handler function, whose address is provided by the program. Other options that can be specified when making the sigaction( ) call include which other signals are blocked during execution of a signal handler, in much the same way as a CPU can mask certain interrupts.
A Unix signal handler can be provided with one of two prototypes. The first signal handler prototype is “void sigHandler(int sigNum).” The first argument is the number of the exception signal, so that one function can be registered to handle multiple signals. A program can request that more information be provided to the signal handler by calling sigaction( ) with the SA_SIGINFO flag. In this case, the Unix signal handler prototype becomes “void sigHandler(int sigNum, siginfo_t sigInfo, void *context).”
The second parameter (“siginfo”) is a structure which contains information about the signal, including some indication of what caused the signal and where it came from. For example, in the case of a SIGILL signal, the siginfo structure contains the address of the illegal instruction. This data can be essential to allow the process to handle the signal properly. The third parameter (“context”) provides access to the processor state (including all subject registers) at the time the signal was raised. Again, this data can be essential to allow correct handling of a signal. The signal handler is allowed to modify this context; when execution is resumed, the subject registers are then restored to the values of the modified context.
In both embedded and non-embedded CPU's, one finds predominant Instruction Set Architectures (ISAs) for which large bodies of software exist that could be “accelerated” for performance, or “translated” to a myriad of capable processors that could present better cost/performance benefits, provided that they could transparently access the relevant software. One also finds dominant CPU architectures that are locked in time to their ISA, and cannot evolve in performance or market reach. Such architectures would benefit from “Synthetic CPU” co-architecture.
Program code conversion methods and apparatus facilitate such acceleration, translation and co-architecture capabilities and are addressed, for example, in the co-pending patent application, U.S. patent application Ser. No. 10/439,966, filed on May 16, 2003, entitled Block Translation Optimization for Program Code Conversion and assigned to the same assignee as the present application, the disclosure of which is hereby incorporated by reference into the present application. Exception handling is one attribute of many subject programs which may be encountered in the course of program code conversion.